Point of service transaction management for service facilities

ABSTRACT

The present invention enables the collection by credit/debit card payment of customer co-pay and self-pay charges via an integrated point-of-service transaction management system and method. The system and method of the present invention may assist health care facilities in the collection of co-pay and self-pay charges at the time service is rendered. The present invention can be implemented anywhere cash, checks, credit cards or debit cards are accepted for payment.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Der. No.13/478,814 filed September 6, 2013, which is a continuation of U.S.patent application Ser. No. 12/502,730 filed Jul. 14, 2009, which is acontinuation of U.S. patent application Ser. No. 10/719,889 filed Nov.21, 2003, which claims the benefit of priority to U.S. ProvisionalPatent Application No. 60/428,311, filed Nov. 22, 2002, and to U.S.Provisional Patent Application No. 60/428,977, filed Nov. 25, 2002, theentire disclosures of which are hereby incorporated herein by referenceas if being set forth herein in the entirety.

FIELD OF THE INVENTION

The present invention relates to an integrated point-of-service paymentmanagement system. In particular, the present invention provides a new,useful and non-obvious integrated point-of-service payment managementsolution for service facilities, such as health care facilities, therebyenabling the use of cash, credit and debit cards for collectingcustomer's co-payments and self-payments, and thereby enabling reportingand tracking of collection performance.

BACKGROUND OF THE INVENTION

Currently, when a customer, such as a patient, receives some form ofservice, such as treatment or another service, from a service provider,such as health care at a health care facility, the customer may beresponsible for paying some portion of the charges associated with theservice, such as treatment, such as in the form of a co-payment orself-payment. Such payments are currently accepted at the time ofservice with cash or check, but not generally with credit or debit card,and the remainder of the co-payments are generally billed. Theacceptance of such payments only by cash or check, particularly in thehealth-care industry, is generally a function of a lack of integrationof accounting between office locations, departments, or the like, suchas a lack of integration of accounting records kept by a hospital or adoctor's office with other office systems. Further, the acceptance ofsuch payments only by cash or check is generally a function of a lack ofintegration between a customer record, such as a patient record, andfinancial records. For example, a patient in the health care industrymay visit two different departments in a hospital, within the same day,and co-payments made by that patient may not be recognized by the systemas being associated with that patient in that day, or as having beenpayable to multiple departments in that same day, prior to departure ofthe patient from the hospital. Some service providers now offer anability for customers to pay past due co-payment or self-paymentbalances via the internet or other after-service mechanism, but the timeand effort due from the customer, in addition to the amount of thepayment due, may cause many customers to not pay the past due balance.

Unfortunately, when payments due are not collected at the time paymentis due, a significant amount of the revenue associated with suchpayments thus may be lost. This is due to the fact that, when billedco-payments cannot be collected, revenue is lost. Such non-payment offees due increases dramatically when the customer is allowed to leavethe service location without being required to make payment. Currently,individual delinquent co-payment amounts in most services industries aresmall—often in the range of $10.00 to $50.00—and therefore are generallynot worth the cost of pursuing the customer for collection. However,such small amounts can collectively add up to millions of dollars ayear.

Furthermore, even in circumstances in which balances due can becollected from customers, the cost of obtaining those past due paymentsmay exceed the amount received from the payment. For example, majorhealth-care providers may need entire departments staffed by largenumbers of employees just to track and obtain past due payments.

Additionally, to the extent service providers, such as hospitals, doforce collection of balances due upon entry or exit, limited paymentlocations are generally available. For example, a hospital may have onlyone or two locations from which payment can be accepted, and thus allcustomers are funneled to those one or two locations. However, theinconvenience of leaving the department the customer was serviced at,and/or the inconvenience of waiting in lengthy lines, nonetheless causemany customers to depart without making payments due.

In view of the foregoing, a need has thus been recognized for a systemwhich allows for the collection of customer co-payments and self-paybalances through an integrated credit/debit card point-of-servicesystem, and preferably for a system that can be implemented in variousservice areas within a single location, and across multiple locations(often referred to as “campuses”). The implementation of such a systemwould enable service providers, such as health care facilities and thelike, to gain significant heretofore unrealized revenue.

BRIEF SUMMARY OF THE INVENTION

The present invention includes a method and system that enables thecollection by credit/debit card payment of customer co-pay and self-paycharges via an integrated point-of-service transaction managementsystem. The system and method of the present invention may assist healthcare facilities in the collection of co-pay and self-pay charges at thetime service is rendered, while also providing detailed collectionreporting and tracking The present invention can be implemented anywherecash, checks, credit cards or debit cards are accepted for payment.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The various features of the present invention and its embodiments willnow be described in greater detail with reference to the drawings of anembodiment of the present invention, and various related components,wherein like reference numerals designate like elements, and wherein:

FIG. 1 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 2 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 3 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 4 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIGS. 5A-C are screen shots which illustrate aspects of an embodiment ofthe present invention.

FIG. 6 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 7 is a block diagram which illustrates the general architecture ofan embodiment of the present invention.

FIG. 8 is a block diagram depicting an administrative overview of thesystem of the present invention.

FIG. 9 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 10 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 11 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 12 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 13 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 14 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 15 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 16 is a block diagram depicting an overview of the Point-of-ServiceApplication of the system.

FIG. 14 is a block diagram which illustrates the operation of the MainMenu of the system.

FIG. 18 is a block diagram which illustrates the operation of the CashTransfer function of the system.

FIG. 19 is a block diagram which illustrates the operation of theProcess Payment function of the system.

FIG. 20 is a block diagram which illustrates the operation of thePayment Entry function of the system.

FIG. 21 is a block diagram which illustrates the operation of thePayment Collection function of the system.

FIG. 22 is a block diagram which illustrates the operation of the LogPayment function of the system.

FIG. 23 is a block diagram which illustrates the operation of the CloseTerminal function of the system.

FIG. 24 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 25 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 26 is a screen shot which illustrates an aspect of an embodiment ofthe present invention.

FIG. 27 is a block diagram which illustrates the operation of a firstaspect of the Data Import function of the system.

FIG. 28 is a block diagram which illustrates the operation of a secondaspect of the Data Import function of the system.

FIG. 29 is a block diagram which illustrates the operation of the DataCleanup function of the system.

FIG. 30 is a block diagram which illustrates the operation of the DataExport function of the system.

FIG. 31 is a block diagram which illustrates the operation of thePolling Application of the system.

FIG. 32 is a block diagram which illustrates the operation of the DailyInteractive Process and Batch Interface Process (Periodic) of thesystem.

FIG. 33 is a block diagram which illustrates the general architecture ofthe system.

FIG. 34 is a screen shot illustrating an aspect of the presentinvention.

FIG. 35 is a screen shot illustrating an aspect of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

It is to be understood that the figures and descriptions of the presentinvention have been simplified to illustrate elements that are relevantfor a clear understanding of the present invention, while eliminating,for purposes of clarity, many other elements found in typical paymentapplications, networks and systems. Those of ordinary skill in the artwill recognize that other elements are desirable and/or required inorder to implement the present invention. But because such elements arewell known in the art, and because they do not facilitate a betterunderstanding of the present invention, a discussion of such elements isnot provided herein. The disclosure herein is directed to all suchvariations and modifications to the applications, networks, and systemsdisclosed herein and as will be known, or apparent, to those skilled inthe art.

The present invention provides for an integrated point of servicetransaction management system that enables the collection of feesaccrued as a result of services rendered by a service provider at asingle service location, or across multiple locations. To facilitate thecollection of fees, a customer assessable terminal may be located ateach point of service at a provider location. The terminals provideaccess, via a network, to at least one remote database capable ofstoring, accumulating and structuring information related to servicesassociated with the customer, and capable of accessing multiple otherdatabases. Customers may have the ability to pay or pre-pay forservices, while any authorized user of the system may be able to trackpayments, services and the like via access to the remote database.

The present system allows for an optional and configurable “discount” ininstances of immediate payment of services rendered at a point ofservice. Discounts or credits may also be provided for timely paymentsof credit accounts, overdue accounts, and the like. Discounts andcredits may take the form of instant payment reduction, coupons orcredits for future services, and interest-free financing, for example.

Further, the system may also provide for the standardization of cashmanagement processes and procedures, while simultaneously providingenhanced reporting capabilities, the latter resulting in improvements inareas such as effective staff management and auditing, e.g. a “papertrail”. The paper trail created allows the system to provide a tool forthe auditing and tracking of transactions for every user of the system.A customer using the system may be able to track expenses and servicesrendered, while a provider of services may be able to audit anemployee's use of time and resources, for example. System reporting maybe tailored to assist a provider of services in determiningprofitability, efficiency and utilization, for example. Such tools aredesired by both for profit and non-profit service providers, such as forthe controlling of expenses and assets.

The system and method of the present invention also preferably complieswith all privacy portions of federal legislation (e.g., the HealthInsurance Portability and Accountability Act, or “HIPAA”). As discussedhereinbelow, user access may be provided based on varying levels ofsystem access and information entered into the system, and thus privacymay be protected by only allowing access by authorized users with theappropriate level of access.

Importantly, the benefits of the present invention can be obtainedwithout the investment of substantial financial resources. Due to theutilization of existing infrastructure (such as PC's, LAN/WAN, printers,servers, T-1 Internet access, etc.) and minimal hardware purchaserequirements, the cost of implementing the system and method of thepresent invention is low. The system and method of the present inventionis also capable of interfacing with existing patient management andpatient accounting systems such as, for example, InVision.®. andSignature.®. (both of which are offered by Siemens Medical SolutionsHealth Services Corporation).

Throughout the instant disclosure, it will be appreciated that severalterms may be used interchangeably with one another, some of which arediscussed hereinbelow.

Referring now to FIG. 1, depicted is a screen shot to access, open, orotherwise activate a point of service (POS) terminal in the instantinvention. Of note, upon log-in, or opening of the POS, the most currentversion of the present invention may be presented for viewing at the POSfrom the remote access point, thereby the present invention provides, atleast in part, a thin client aspect for the use of the presentinvention, thus limiting processing resources needed at the POS. Forexample, interactions at each POS, other than those interactionsdiscussed hereinbelow, may be entirely browser based.

The remote access point may, in an embodiment, present at the POS, uponlog-in request, the most-current version of the present invention to theuser as needed. As will be apparent to those skilled in the art, thepresentation of the most current version at the POS may additionallyentail the downloading of the most current client-side aspects of thepresent invention to the POS, such as aspects to run magnetic cardreaders, for example. Further, log-in for the present invention may berole based, wherein one or more multiple roles may be assigned uniquelyto each log-in, or to each terminal-wide log-in, for example.

In FIG. 2, a new batch has been opened, such as by presentation of thelatest application from the remote access point to the POS, wherein thePOS may begin batching information upon opening of the POS, or whereinthe POS may provide information received at the POS to the one or moreremote databases in real time. It will be apparent to those skilled inthe art that, thereby, information regarding all customers, in alldatabases, may be accessible simultaneously from any POS within theservice provider at any given time, or substantially at any given timein an embodiment wherein information is batched at each POS for responseto a polling application request for download to the remote accesspoint.

As illustrated in FIG. 2, customer registration information may berequested in order to initiate a transaction. Receipt of informationwill cause the present invention to search existing customer databasesfor a match and, if no match is found, will cause the issuance of arequest for information to register the customer. Upon receipt ofregistration of a new customer, the customer registration may be storedto the existing registration database for future accessing. If thecustomer information entered causes location of an existing customer orcustomers, matches will be returned to allow for selection of thecorrect customer, as illustrated in FIG. 3.

Of note, registration of a new user causes records of that user tobecome immediately available to all POS's through the use of the presentinvention. Further, it will be apparent to those skilled in the art thatnew customers may be registered in person at a POS, or, for example, bytelephone, simply by granting registration information to a POSoperator, for example.

Upon location or registration of a customer, the current transactioninvolving that customer may be processed for payment, as illustrated inFIG. 4. As illustrated, existing payment, or non-payment, data isintegrated with current payment due data in FIG. 4, and each of theexisting payment, non-payment, and current payment due data items may beresident in different databases, or at different locations, for example.As illustrated in FIG. 4, in accordance with the ability to accessmultiple systematic databases simultaneously, the present invention mayprovide prior balances due or payments made, current balances due orpayments made, and the ability to pay and get approval of payment, allfrom a single access point. Additionally, certain balances may beflagged, such as by color, in instances wherein those balances are ofparticular note, such as wherein the flagged balances constitute “baddebt” that has been unpaid for greater than a specified time. For easeof use, a “mouse-over” feature may be made available, whereby a user mayplace the cursor over payments paid or due in the payment screen, andmay be shown predetermined relevant information regarding the paymentcorrespondent to the cursor location.

Upon entry of a payment, for example, the system may track the type ofpayment, go outside the system via the network to gain any necessarypayment approvals, such as credit card approvals, and pay down balanceswith that payment, such as in a cascade format wherein the currentamount due, and then each subsequent oldest balance due, in turn, arepaid, from the access screen of FIG. 4. As illustrated, typical paymentoptions may be accepted at the POS, including, but not limited to, cash,credit cards, debit cards, and EFTs, for example.

As illustrated in FIGS. 5A, 5B, and 5C, selection of different paymentmethodologies may present different information requests to the user ofthe POS, wherein the user may be a customer or a facilitator.Alternatively, upon swiping of a payment card in a card-readerassociated with the POS, like information regarding the customerpurchase method may be generated automatically. Further, as illustrated,the payment screen may include relevant payment codes, each of which maycorrespond to areas within, or associated with, the service providerlocation. Thereby, only certain eligible payment codes may be acceptedfor current payments due in the screens of FIG. 4 and FIGS. 5A-C.

The inclusion of payment codes allows for acceptance at a POS ofpayments from multiple categories of an accounting ledger. For example,in a health care facility, payments may be accepted for patientservices, and non-patient services, differentiable by entry of therelevant accounting code for the services provided, in conjunction withthe receipt of payment, at the POS. Thereby, an audit trail is createdthrough the use of the present invention, at least in that the requiredaccounting code may be associated with any received payment, and mayadditionally b e associated with the location and terminalidentification at which the payment was received, and the user logged tothat terminal at the time of payment. Thus, receipts printed in hardform, as discussed hereinbelow, may provide a paper audit trail, andtracking via the one or more remote databases may provide a soft copyaudit trail.

Upon receipt and approval of payment, a receipt may be generated, suchas that shown in FIG. 6. The receipt may be generated in soft-form, andmay be stored to one or more databases in the system of the presentinvention, and may be printed in hard-form and given to the customer, aswell as being stored in hard-copy files at the service providerlocation. Hard copy receipts may be generated by request at the POS, orautomatically.

Referring now to FIG. 7, depicted schematically is a visualrepresentation of a payment system in accordance with the presentinvention discussed in the screen flow hereinabove. Various aspects ofthe system shown in FIG. 7 will be further appreciated from thediscussion of the figures provided further hereinbelow.

With respect to the discussion of the Figures hereinthroughout, and asused herein, HTML, or HyperText Markup Language, refers to one of theauthoring languages used to create documents on the World Wide Web.HTML, as used herein, is contemplated as exemplary of networkprogramming languages, and is thus interchangeable with other terms andprogramming language types that will be apparent to those skilled in theart, including, but not limited to, Java, XML, XSL, xHTML, and the like.HyperText Transfer Protocol (HTTP), and associated protocols with otherlanguage types, are the underlying protocols used by the World Wide Web.HTTP and similar protocols define how messages are formatted andtransmitted, and what actions Web servers and browsers should take inresponse to various commands. For example, when a URL is entered into abrowser, this sends an HTTP command to the Web server directing it toretrieve and transmit the requested Web page.

As used herein, a link or hyperlink is a navigational link from onedocument to another, or from one portion (or component) of a document toanother. Typically, a hyperlink is displayed as a highlighted word orphrase that can be clicked on using the mouse to jump to the associateddocument or document portion.

As used herein, a network, such as an internet, intranet, or extranet,is a collection of interconnected public and/or private computers orcomputer networks that are linked together by a set of standardprotocols, such as TCP/IP, HTTP, FTP and Gopher. A network may be orinclude: a LAN (local area network), which is a computer networkspanning a relatively small area, but which may be connected to otherLANs to form larger networks, such as by telephone lines, leased lines,satellite, radio communications, or a T-1 line; or a WAN (wide areanetwork), which is a network spanning a larger area, and which may beformed of interconnected ones of the LANs. In a typical embodiment, aLAN may connect a series of workstations and PCs to at least one server,and one or more nodes on a LAN may include a CPU that executes programsand/or platforms.

The system and method of the present invention, as illustrated withrespect to FIG. 7, may include a browser-based point-of-sale systemrunning over an existing LAN/WAN that is easy to maintain and support,such as a web browser interface running in association with at least oneMS SQL Server 2000 and at least one Web page server, and that may beintegrated with one or more legacy systems. Devices utilizing wirelessLAN, i.e. WI-FI, may be connected to the present invention. Co-paymentsor self payments may be collected at various service areas throughoutone or more facilities, such as by using existing PC's aspoint-of-service terminals. Acceptable forms of payment may include, butnot be limited to, cash, checks, credit cards (e.g., Visa.®.,MasterCard.®., American Express.®., Discover.®.) and debit cards, suchas with the use of a personal identification number (PIN).

Specifically, as illustrated in FIG. 7, the system and method of thepresent invention may make use of manual cash amount entry and magneticcard swipes and/or PIN pads at each point-of-service (POS) terminalwhereat services are offered, thereby providing for fast and reliablecredit/debit card processing. In an embodiment, credit card and debitcard transactions may be processed over the Internet rather than overanalog lines, thereby significantly reducing costs and providing for aquick response time for credit/debit transaction approvals (i.e. under10 seconds per transaction).

As illustrated in FIG. 7, customer data may be taken upon customerregistration at the POS. Alternatively, the customer registration may beintegrated with prior registration from existing systems, which systemsmay provide an ability to recognize the existing customer, to associatepayments made with that customer, and/or to pull records of thatcustomer, among other actions, simply based upon entry of a customerdata item, such as a name, phone number, or swipe of the customer's cardfor payment, to the system of the present invention. For example, apatient may be seen in Dept. A of a hospital, and the doctor in Dept. Amay electronically pull that patient's chart and payment records, make adiagnosis, electronically enter that diagnosis, such as in a “notes”section of the input, and have entered for that patient a currentpayment due. The patient may then proceed to the exit of Dept. A, atwhich point the patient may be checked for registration, may present anamount currently due, may swipe a credit card to allow for collection ofa co-payment currently due for the treatment received in accordance withthe current payment due previously entered. Additionally, prior balancesdue may be paid by the customer. The card reader, for example, may, viathe internet, request acceptance of the payment, and may return anacceptance of the entered current payment, and/or payment of one or moreprior balances. The system of the present invention may then access thatpatient's records, the treatment received, any past-due balances, andthe current diagnosis including any prescription reminders, from thelegacy systems of Dept. A, and may adjust such data as necessary inlight of the transaction.

More specifically, with respect to FIG. 7, a series of existing legacyapplications, and the system of the present invention, may receiveand/or provide accessibility to a plurality of updated flat files, whichmay be updated in real time, such as through the use of the presentinvention, and such as at the POS, and/or which may be batch updated,such as nightly. The data to update these existing applications may beexported from the POS application, via the use of the present invention,and the data from these flat files may be imported to, or exported from,the POS, via the existing applications or via other POSs of the presentinvention, such as via real time access, or via a polling of theapplications, for example. Access via a network to internal and externalapplications may thus be provided via the use of the present invention,such as via an SQL server. Such SQL server may thereby interconnectand/or interact with both a centralized administrator and the POS.

FIG. 8 illustrates an embodiment of an administrator for use in thepresent invention. The administrator may be, in whole or in part,resident at a centralized location communicatively connected to each POSat the service provider, and/or may be resident, at least in part, ateach POS. The administrator may allow for logging of registered users,such as by entry of a user name and password, and may provide levels ofaccess by user or permission type, in accordance with the user orpermission type associated with the particular login entered, whichassociation may be provided, for example, in at least one databasewithin, or associated with, the administrator.

For example, the system and method of the present invention may includethree levels of user security, such as POS User, POS Supervisor, and POSAdministrator. The POS User may have the lowest level of access to thesystem. The POS User can thus log into a POS terminal, collect payments,and close out a POS terminal. The POS User can change a password butcannot perform other supervisor or administrative tasks. The POSSupervisor may have the same privileges as the POS User but may alsoperform additional activities, such as re-assigning default printers toPOS terminals, maintaining user profiles for a department, closing out adepartment, and reporting. There may typically be one POS Supervisor perservice area or department. The POS Administrator may have the sameaccess privileges as the POS Supervisor but may also perform additionalactivities, such as setting up POS Supervisor user profiles, definingand modifying the topology (Campuses, Departments, POS Terminals,Network Printers), and all reporting.

Within the administrator, a main menu page, which may be selectable andnavigable via methods apparent to those skilled in the art, such aspull-down menus, hot keys, treed menus, links, hyperlinks, and the like,may provide access to settings, setup, account management, generatingreports, manual overrides, and support/help, for example. Settings mayprovide the manner in which the application process progresses, such aswhether current payment is enabled when there is an existing debt, flatfile update recurrences, and the like. Setup may allow for setup forcertain facilities, such as adding, deleting, or modifying campuses,departments, groups, offices, terminals, and the like. Accountmanagement may allow for master control of accounts, such as numbers ofaccounts, user permissions and security roles, and the like.Administration may additionally provide, for example, maximum open timesfor each POS, accounting codes allowed, discounts, HL7 and flat fileinterface settings, allowable payment types, one or more entity treesdefining all related entities, and relevant locations, in a serviceprovision system, and the like.

For example, to facilitate administration, an entity tree may beavailable via one or more POS's for an authorized accessor, and maythereby map locations, campuses, departments, and all POSs in anyservice provision system, keyed by level of each POS. Such an entity mapmay be available via a single viewing screen, for example. Further, forexample, FIGS. 34 and 35 illustrate an embodiment of such an entity map,and the manner in which such an entity map may have made theretoadditions, deletions, and/or modifications. As illustrated in FIG. 34, aservice provider may be hierarchically organized by system, hospital,campus, department, and actual terminal at the POS. The treed entity mapmay be expanded or retracted, such as by selecting plus or minus buttonsadjacent to the relevant portion of the tree. As illustrated in FIG. 35,hospitals, campuses, departments, or terminals may additionally be addedor deleted or modified, such as with a convenient click, as necessary ordesired, through the use of the present invention. This may additionallyallow for reporting at each level in any system, as discussed furtherhereinbelow.

Reporting may allow for generation of administrative reports, and may beaccessible from within the administrator or from each POS. For example,the present invention may provide for generation of end-of-shift andbatch or department closure reports, as well as pre-defined paymenttransaction reports, and additionally may log errors, notes on eachtransaction, such as for batch delivery to back-end accounting, or thelike. Further, for example, the present invention may provide, via theadministrator main menu or the POS, the production of user-definedpayment transaction reports using third party software, such as CrystalReports.®. (Seagate Software, Inc.). Manual interaction and override mayallow for manual control of generally automated processes, such asforcing actions to be taken.

Reports may be accessed, from the administrator and/or from the POS, byselecting a “Reports” selector as illustrated in FIG. 9. Availablereports may be selectable from a menu, such as a treed menu or splitscreen menu, as illustrated in FIG. 10. Reports may allow for a reviewof, for example, terminal operator efficiencies, terminal efficiencies,terminal transactions, or the like, as illustrated in FIGS. 11 and 12.Such reports may additionally be available by provider site, for overallterminals present at each site, such as the report illustrated in FIG.13. Reports may preferably be available upon the closing of one or moreterminals, and thereby upon generation of a batch update from those oneor more terminals, for example.

In a specific reporting embodiment, the use of the system and method ofthe present invention across a service provider location or locationsmay allow for generation of efficiency reports, such as that illustratedin FIG. 14. As illustrated, the present invention may track registeredcollectables versus attempted collections, patients registered versuspatients collected from, amount collected versus amount that could havebeen collected, and like factors reflecting the efficiency ofcollections for a service provider per terminal or per site.

In an additional exemplary reporting embodiment, an open batch reportmay be generated, as illustrated in FIG. 15, whereby open batches, i.e.active terminals, are reported. Such a reporting may include both openand closed batches, and may provide the time for which batches have beenopen. For example, to the extent particular batches have been open, orhave otherwise gone un-reconciled, for greater than a predetermined timeframe, those batches may b e flagged in the report, such as beingillustrated in red color.

Returning now to FIG. 7, the POS may include a series of links,hyperlinks, and/or web pages that provide access to and interconnect atleast one network with accessibility to credit and/or debit cardauthorization applications, and that provide access to a plurality ofcard readers that provide for the swiping or typing of card information,for entry of that information as discussed hereinabove. In an exemplaryembodiment, MagTek.®. IntelliPIN.®. magnetic stripe readers and PINentry pads, by MagTek, Inc., may be employed in conjunction with one ormore Web server/payment servers and an Internet connection, such as aT-1 or higher connection, to effectuate the reading and approval ofdebit and/or credit cards. In a preferred embodiment, a device such asthe MagTek.®. IntelliPIN.®. may combine a magnetic stripe card readerand PIN entry pad, may be secure and tamperproof, may encrypt data, suchas user PIN numbers, automatically for added security, may be smallenough to conserve space, may provide graphical interface for acustomer-user to easily engage the unit without training, and may beeasily attached to a PC designated to be a POS terminal. An exemplaryflow of this POS aspect of the application of the present invention isillustrated with more particularity in FIG. 16.

The real time accessing of payment data securely allows for the up-frontpayment of co-payments and self-payments, for example. Such up-frontpayments eliminate bad and uncollectable debt, and thereby provide animprovement over the back-ended payment systems of the prior art.Further, in an embodiment wherein information, such as payments, istracked in real time, knowledge of payments as those payments occur isan improved methodology of eliminating bad debt over the occasionalupdates of the prior art. Also, back-end payments remove incentives onthe customer to pay, as services have already been received and thecustomer has left the premises in back-end payment systems. For example,a customer is inconvenienced in systems wherein the customer, afterdeparting the location of the service provider, is to access a paymentsite via the internet, and the customer, after having departed, has noincentive to suffer that inconvenience. Up-front payment eliminates thisdisadvantage. Further, up-front payment allows for elimination of theexpense of bill generation, delivery, and processing after a customervisit. Additionally, up-front payment may eliminate customer confusionover bills received months after services are provided. Thus, as will beapparent to those skilled in the art, up-front payments and eliminationof bad debt provide for increased revenue for the provider of the methodand system of the present invention.

As illustrated in FIG. 16, a customer or facilitator may have access to,for example, a card swiper or keypad entry, or additionally to, aninteractive screen, such as a touch screen, to allow for interactionwith, and entry of card information to, the POS. Further, a facilitator,such as a cashier, may have access to the POS information availableregarding the customer, and/or to additional information not within viewor access of the customer, as discussed hereinabove. The applicationmain menu at the POS may allow for entry of card information, or entryof cash payment, or entry of a cash transfer, such as an EFT, forapproval from a remote authorizer, as discussed hereinabove, whichapproval may be accessed, for example, via a network, also as discussedhereinabove.

Thereby, such swiped card authorization, or past due balance informationto be paid by the swiped card, may be associated with paymentinformation from other groups, offices, or departments of the sameentity, or within the same facility, such as via the batch updates uponterminal closure for that POS. For example, a patient balance due froman X-ray in a medical center may be added with a balance due from a giftshop and from a cafeteria to generate a total balance due.

Further, as illustrated hereinabove, swiping or entry of a card orpatient name or information may cause the accessing of customer, such aspatient, records, including viewing and entering payment amounts, whichmay include past due payments, entry of transaction details, and/orgeneration of a receipt. Thus, the system and method of the presentinvention may provide for an audit trail by quick receipt printing usingexisting network printers, such as printing two copies of the receipt onplain white 81/2.times.11 paper, for example. Further, the POS mayprovide for batch control, such as generation of batch updates from thatPOS to the flat file updates.

Batch interface files may be produced to update current customer, suchas patient, accounting systems with payment or other information.Further, the present invention allows patient registration informationto be accepted real-time in HL-7 format (an ASTM-defined commoncommunication format for healthcare electronic data transfer) fromexisting patient management systems, and allows for batch association ofthat registration information with other information, such as paymentsdue. FIG. 17 illustrates the flow of a batch control performed at, or inassociation with, the POS of the present invention.

As illustrated in FIG. 17, a user may login and have the necessarypermissions to engage the batch processes. An authorized user may engagein batch control, such as by viewing batch information, creating newbatches or using the current batch, viewing the cash or dollar value ofthe current batch, and the like. FIG. 18 further illustrates recordationof a transaction, in a specific embodiment implementing a valuetransferal.

FIG. 19 illustrates an implementation of the system and method of thepresent invention wherein a particular customer, such as a patient, maybe searched for and/or selected. For example, a POS user may enter asearch criteria, such as via a POS terminal, to locate a particularcustomer. That search may activate both the POS and legacy systems, mayaccess the files thereof, and may return a listing of customers matchingthe search criteria, as discussed hereinabove. If no matches arereturned, the customer may be added as a new customer, such as via thePOS. If one or more matches are found, the customer record may beaccessed, such as via a hyperlink to the location of the matchingrecords, and all fields of the terminal may be populated by the selectedmatching record.

In an exemplary embodiment, the search for a matching customer may beperformed on all records, including legacy records, via a translation ofall records to a format acceptable to the system of the presentinvention, including such as by a batch download of converted legacyfiles accumulated at intervals. For example, a set of data types forexisting legacy systems may be entered to the system of the presentinvention, and, upon an activation of accessing legacy records, thesystem and method of the present invention may endeavor to match thelegacy records at the to-be-searched locations to one of the known datafile types. Once a matching type is found, the records may be accessedand translated to a format suitable for use in the present invention.

FIG. 20 is a flow diagram illustrating the entry of payments andtransactions to the POS. For payments, the POS display may display, tothe customer and/or the facilitator, the current payment due, relatedand recurring payment information, and any overdue balances for anydepartments. The customer may self pay, or co-pay, via payment entry,and may select the payment method and any discounts, coupons, or thelike to be applied, as illustrated hereinabove. The facilitator mayenter the transaction occurring at the POS, such as into a transactionentry interface, which entered transaction may include details of thetransaction, such as payments due, services rendered, and the like.

The transaction so entered may additionally include the entry oftransaction notes. Such notes may provide a communication channelbetween front-ended personnel, such as those at the POS, and back-endedpersonnel, such as those in accounting. For example, such notes mightinclude that a past due balance was not collected because the customerasserted at the POS that a check had been sent the previous day, andsuch a note may thereby alert accounting to that fact.

FIG. 21 illustrates an exemplary payment collection in accordance withthe present invention. Payment collection may include assessment of thepayment type. It may be assessed that a check must be approved, andhence certain information must be collected from the customer in orderto receive and insure eventual approval of, and collection on, thecheck. It may be assessed that a customer or another user, such as afacilitator or guardian, has swiped a credit or debit card. The datagained from the swipe of the card may generate an automated approvalrequest from the card reader or keypad. The automated approver mayreceive a request from the approval location, such as from an approvalserver connected via the internet to the system of the presentinvention, for additional information, such as verification of a billingaddress or home phone number of the customer. This information may thenbe forwarded to the remote approver, and payment via the card may beapproved.

Further, as illustrated in FIG. 22, a payment, once made, such as beingaccepted or denied, may be logged. This payment log may be recorded inspecified details to, for example, a storage location within orassociated with the POS or administrator of the present invention.Further, a customer receipt incorporating selected portions of thesepayment log details may be generated at the POS upon receipt of payment,and/or upon receipt of past due payments, as discussed hereinabove.

As illustrated in FIG. 23, a user, such as the facilitator, may, ifauthorized to do so based upon user permissions, engage in terminaloperations on terminals associated with the system and method of thepresent invention. For example, an authorized user may close or settle aterminal, either locally or remotely. A terminal may be terminated bylogging off, or by shutting down the terminal. A terminal may be settledby summarizing, logging, or batching all transactions from thatterminal.

Settling a terminal may include, for example, closing the terminal, asillustrated in FIGS. 24, 25, and 26. Closing a POS terminal may beanalogous to closing a cash register out, for example, and thus mayinclude settling cash payments made at the terminal, credit and debitpayments made at the terminal or other payments made at the terminal.For example, the present invention may provide a continuous audit trail,whereby monies, and custody thereof, are tracked from being due untildeposit.

Thus, upon closing of a POS terminal, monies due and paid may bedifferentiated by type, such as patient payments versus non-patientpayments, which differentiation may be made based on accounting codesentered for each transaction, as discussed hereinabove. The settlementof differentiable payments may be made, for example, in separatewindows, and may cause the generation of separate payment reports.Further, for example, different methods of payment, as evidenced by thebatch payment data at the POS, will cause different information to berequired to track each payment method type. For example, electronicpayments, such as credit, debit, EFTs, or the like, may show approvalcodes or the like. Cash payments may request that a bank bag number beentered into which cash is placed, as illustrated in FIG. 24. The amountof cash placed into the bag may require reconciliation prior to terminalclosing, and bags may be later combined in other areas of the serviceprovider location, such as into larger bags, and those larger bagnumbers are also tracked by the use of the present invention at eachcashier terminal at which bags are dropped.

Further, the present invention may ensure entered cash bags exist andare approved for cash placement, and may track from where, and to where,and from whom and to whom, bags are passing. Additionally, bag numbersmay be changed, and those changes may be tracked in the presentinvention. Thereby, a final manifest for daily, or hourly, or weekly,cash may be generated, and this manifest may be compared to bank depositslips for final reconciliation. Consequently, lost, unreconciled, orundervalued bags may be flagged through the use of the present inventionat any point, including upon deposit at a bank.

As illustrated in FIG. 27, data importation may occur in the presentinvention via numerous methodologies. FIG. 27 specifically illustratesan embodiment wherein HL7 is imported to the method and system of thepresent invention. It will be apparent to those skilled in the art, asdiscussed hereinabove, that data importation may include: an accessingof external data, such as by user request or by customer action, such asby a card swipe identification; an assessment of the data type of thatexternal data; a conversion, based on the data type assessed, to thelanguage of choice for implementation of the system and method of thepresent invention; and a presentation of the translated conversion.Similarly, it will be apparent that data exportation may occur in asimilar manner. In the exemplary embodiment of FIG. 27, an HL-7conversion via a flat file is performed. The importer links, via a TCPor similar receiver, to the HL7 transaction, accepts the transaction asa flat file, polls until the flat file is accepted, and converts the HL7flat file to XML. This importation methodology keeps all interactions ofthe application with externalities contained within one centrallocation.

FIG. 28 is a flow diagram more specifically illustrating an embodimentof data importation for use in the present invention. In the illustratedembodiment, a flat file is designated for bulk insertion at apredetermined interval, such as once daily, such as at night. Adesignated receiver, such as a POS Inbox, at the receiver location mayreceive the batch flat file update and may parse to each applicablerecord, such as passing updated information on client A to the uniquerecord of client A. Each patient record may thus be updated via thebatched import files, and new records may be created automatically fornew patients. Thus, both individual patient records and records of allpast and existing patients may be updated by the batch flat fileimportation. The batch update may include transaction types, departmentsin which transactions occurred, payments, balance changes, and the like.

Thus, through the use of the system and method of the present invention,the data importation may be customizable, such as by using data from anexisting, legacy, or input format into a standardized, genericizedformat. For example, for each type of data file that the system is toaccept, a format file may be created associated to the POS, such aswithin or associated with the configuration files, that may be used tomap the source data into the destination format, as discussedhereinabove.

Further, as illustrated in the exemplary flow diagram of FIG. 29, thesystem and method of the present invention may perform maintenance ofdata at predetermined intervals, such as regular data cleanup and thelike. For example, deletions of preselected data types, such asrecurring patients and/or new patients, may be deleted, in whole or inpart, at the start of each new month.

FIG. 30 is a flow diagram illustrating the exportation of data by theuse of an aspect of the present invention. Those skilled in the art willnote that data exportation may be engaged similarly to a dataimportation transaction. More specifically, in the exemplary embodimentof FIG. 30, payments collected may be recorded, such as by a user, suchas the facilitator, and inserted to a location, such as an outbox, uponcollection. Records may be exported, such as in a flat file format, uponissuance of an exportation command, such as from a polling application.

An exemplary polling application is illustrated in the flow diagram ofFIG. 31. As illustrated, the polling application may be running on acentral server. When the predetermined polling time or event is reached,the polling application may poll for data. The polling application maypoll, for example, for particular types of data, such as HL7 data, orfor genericized data, such as flat file data, that may be accepted asgeneric or genericized, such as by translation or conversion, or fordata batched, for example. The polling application may read particularflags set that certain data types have been received and are responsiveto the polling.

Further, as illustrated with respect to the exemplary embodiment of FIG.31, if any portion of data import/export fails for any reason, POSpayments and transactions can still occur while application aspects aredown. For example, since POS transactions are handled separately, userscan still collect money, and/or have credit cards authorized, andadditionally users at other POSs remain unaffected. Further, once aproblem is resolved, the polling application may pick up stored datafrom each POS, resulting in no system data loss. For example, when theaspect is eventually restarted, export files may have been automaticallycreated, such as HL-7 and flat file transactions, and may simply havebeen queued up for export in the order they were received forimportation.

It will be apparent to those skilled in the art that the records of thepresent invention are associated with the users of the present inventionbased upon tracking of information regarding those users to allow thatassociation, such as via one or more databases, such as relationaldatabases. Information which may be tracked, and which thus may berequested prior to the implementation of a user in the system and methodof the present invention, such as to set up a new user account, mayinclude: (a) the number of locations in the provider's network,including name, location, number of campuses and size (such as totalnumber of beds); (b) whether each of the locations have separate ITsystems/staff; (c) whether there is a WAN in place; (d) the type ofInternet connectivity, such as T-1, for example; (e) how many customervisits occur per month per location, and whether or not there are anypeak times where visits are significantly higher than normal; (f) howmany potential POS stations there are at each location; (g) the range ofdollar amounts written off annually for non co-payment collection; (h)the range of dollar amounts written off annually for non self-paycollection; (i) the range of dollar amounts spent annually forcollection agencies fees; (j) what current payment management andaccounting systems already exist at each location; and/or (k) thefacility's preferred server platform.

If not otherwise stated herein, it may be assumed that all componentsand/or processes described heretofore may, if appropriate, be consideredto be interchangeable with similar components and/or processes disclosedelsewhere in the specification. It should be appreciated that thesystems and methods of the present invention may be configured andconducted as appropriate for any context at hand. The embodimentsdescribed hereinabove are to be considered in all respects only asillustrative and not restrictive. All changes which come within themeaning and range of equivalency of the claims hereinbelow are to beembraced within the scope thereof.

What is claimed:
 1. An integrated point of service patient transactionmanagement system, comprising: at least two points of service within asingle health care provider; at least one computing terminal at each ofthe at least two points of service at the single health care serviceprovider, wherein a patient service is offered at a first of thecomputing terminals, wherein a non patient service is offered at asecond of the computing terminals, and wherein at least two of thecomputing terminals are capable of providing payment transactions; andat least one relational transaction database for tracking, remotely fromeach of the computing terminals, at least one customer of the singlehealth care service provider and the payment transactions of thecustomer at each of the computing terminals, wherein paymenttransactions comprise at least one selected from the group consisting ofpatient service self-pay payments from the at least one customer at thesingle provider, nonpatient service payments from the at least onecustomer at the single provider, overdue non patient service payments ofthe at least one customer to the single provider, and overdue patientservice self-pay payments of the at least one customer to the singleprovider; wherein the terminals communicate with the at least onerelational database via at least one network to provide to the healthcare service provider, within the at least one relational database, acorrelating of the at least one customer to the at least one paymenttransaction from the at least one customer.
 2. The system of claim 1,wherein the single provider is a health care facility.
 3. The system ofclaim 1, further comprising a registration, wherein the registration ofthe customer occurs at one of the at least one terminals, and whereinsaid at least one database stores registration information, associatedwith the customer, as entered by a user of the at least one terminal. 4.The system of claim 3, further comprising an account manager, whereinthe registration information stored in the at least one database isaccessible and manipulable via the account manager.
 5. The system ofclaim 1, further comprising an administrator, wherein users of thesystem are assigned at least one level of access in the administrator.6. The system of claim 1, wherein the at least one terminal acceptsinformation via at least one of a keypad, touchscreen, payment cardreader, and identifying card reader.
 7. An integrated point of servicepatient transaction management system, comprising: a first computingterminal capable of providing payment transactions at a first point ofservice within a single health care provider, wherein a patient serviceis offered at the first point of service; a second computing terminalcapable of providing payment transactions at a second point of servicewithin the single health care provider, wherein a non-patient service isoffered at the second point of service; and at least one relationaltransaction database remote from the first and second computingterminals for tracking at least one customer of the single health careprovider and one or more payment transactions of the customer at thecomputing terminals, wherein the payment transactions comprise at leastone payment transaction selected from the group consisting of patientservice self-pay payments from the customer, nonpatient service paymentsfrom the customer, overdue non patient service payments from thecustomer, and overdue patient service self-pay payments from thecustomer; wherein the first and second computing terminals communicatewith the at least one relational database via at least one network toprovide, within the at least one relational database, a correlating tothe one or more payment transactions from the at least one customer. 8.The system of claim 7, further comprising a registration, wherein theregistration of the customer occurs at one of the at least oneterminals, and wherein said at least one database stores registrationinformation, associated with the customer, as entered by a user of theat least one terminal.
 9. The system of claim 8, further comprising anaccount manager, wherein the registration information stored in the atleast one database is accessible and manipulable via the accountmanager.
 10. The system of claim 7, further comprising an administrator,wherein users of the system are assigned at least one level of access inthe administrator.
 11. The system of claim 7, wherein the at least oneterminal accepts information via at least one of a keypad, touchscreen,payment card reader, and identifying card reader.